Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.08%. Comparing base (fd2cec6) to head (fa56be5).
Report is 14 commits behind head on main.

@@            Coverage Diff             @@
##             main    #2985      +/-   ##
==========================================
- Coverage   96.10%   96.08%   -0.02%     
==========================================
  Files         377      377              
  Lines       55147    55155       +8     
==========================================
  Hits        52997    52997              
- Misses       2150     2158       +8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

Pull Request Test Coverage Report for Build 11934839781

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 5 of 5 (100.0%) changed or added relevant lines in 2 files are covered.
• 8 unchanged lines in 3 files lost coverage.
• Overall coverage decreased (-0.01%) to 96.193%

Totals
Change from base Build 11815057382:	-0.01%
Covered Lines:	53241
Relevant Lines:	55348

💛 - Coveralls

So this PR is checking if an array is not daskified and converts it to a dask array if it's not.

I think it would be important to know why the array was not a dask array in the first place, otherwise we are still possibly loading the data into memory maybe unnecessarily. Tracking back the get_dataset in the base class, the variables are taken from the file here

@ameraner here is the result of my investigation.

The code that you showed me bellow

returns either non daskified or daskified xarray DataArray.

The reason of the "daskification" or not is to be found there

According to what I have seen all the non daskified array are in fact cached_data which is caused due to the the length of the array* the lenght of dtype_size is inferior to cache_var_size you can see this operation done there

Then some non daskified array are transformed into daskify in this part of the code it is depending of the transformation made.

Hi @ClementLaplace , thanks for the analysis! I see, it's quite as @gerritholl was suspecting :) Ok, then I would say it is ok to keep this implementation, in order to make sure that we have homogenised dask array outputs for dataset.